Understanding the ::slotted() Pseudo-Element in CSS
The ::slotted() pseudo-element is used in Web Components to style elements that are passed into a shadow DOM via <slot>. Unlike ::part(), which styles internal elements exposed via the part attribute, ::slotted() targets content projected from outside the shadow DOM.
::slotted(selector) targets elements that are passed into a shadow DOM slot.
It does not affect internal elements created inside the shadow DOM—only slotted (external) content.
You can style properties like color, font, margin, and padding for the slotted elements.
Only the top-level elements of the slot can be targeted; nested elements inside the slotted content cannot be selected with ::slotted().
In this example, the ::slotted(.highlight) selector styles only the <p> element with class highlight that is passed into the <slot> of the shadow DOM. Other elements inside the shadow DOM remain unaffected.
::part() styles internal shadow DOM elements exposed via the part attribute.
::slotted() styles external elements projected into a shadow DOM slot.
::part() allows more granular control over internal structure; ::slotted() is limited to top-level slotted content.
Use ::part() for theming internal parts and ::slotted() for styling content passed from outside the component.
You're building a button component with a shadow DOM and want to let users style the text inside it — should you use ::slotted() or ::part()? Why?
If a user passes a <span> inside a <slot> in your component, and you try to style it with ::part(), what happens and why?
You set up a custom element with a slot and try to style its content using ::slotted(*) — but nothing changes. What’s the most likely mistake?
A designer reports that the text inside your card component’s slot is inheriting global font styles even though you set a reset in the shadow DOM — how do you diagnose and fix this?
Your team’s modal component uses ::part() to expose a close button, but QA says the button’s hover styles aren’t working in some browsers — what could be going wrong?
You’re integrating a third-party web component that uses ::slotted() for content styling, but your app’s global CSS is overriding it unexpectedly — how do you isolate and resolve this?
You’re designing a reusable form field component that needs to allow external styling of both the input (via slot) and the error icon (via part). How do you structure the shadow DOM and CSS to avoid style leakage while keeping flexibility?
Your component library uses ::part() extensively for theming, but performance tests show slow repaints when users dynamically change themes. What’s the root cause and how would you optimize it?
A legacy component uses ::slotted() to style user-provided content, but now you need to support nested components inside slots — what edge cases arise and how do you handle them without breaking existing consumers?
You’re leading a migration from a legacy CSS-in-JS component library to web components with shadow DOM. How do you decide which internal elements should be exposed via ::part() vs. which should remain hidden, and how do you communicate this to 10+ frontend teams?
Your company’s design system uses ::part() for theming across 50+ components, but now you’re adding a new framework that doesn’t support shadow DOM. How do you architect a backward-compatible styling layer without sacrificing encapsulation?
A critical component uses ::slotted() to style user-provided content, but it’s causing layout thrashing in high-frequency updates. How would you redesign the API and styling strategy to support dynamic, performant content insertion at scale?